The mobile IPv6 (MIPv6) described in later-mentioned Non-Patent Document 1 allows a mobile terminal (MN: mobile node) to keep using an interne protocol (IP) address without change before and after changing a connection point to the Internet.
The unchanged IP address in the MIPv6 is an address of the mobile node in a home network domain, and is called a home address. While the mobile node is connected to a foreign network domain, the mobile node can configure an IP address to be used from a subnet prefix notified by the foreign network domain. An IP address configured from the subnet prefix notified by the foreign network domain is called a care-of address, and the mobile node is also reachable over the care-of address.
The mobile node registers the care-of address and the home address at a home agent to create an association with each other so that the mobile node can maintain its reachability regardless of the connection point. In the MIPv6, the home agent is a router within the home network domain of the mobile node, and registers therein a binding of a current care-of address and the home address of the mobile node. This registration is achieved by the mobile node through transmission of a binding update (BU) message to the home agent. If the mobile node is away from the home network domain, the home agent intercepts packets directed to the home address of the mobile node and tunnels the intercepted packets towards the mobile node via the associated care-of address. Based on the above description of the MIPv6, a host (mobile node) performs mobility management in the MIPv6. For this reason, the MIPv6 is also known as a host-based mobility management protocol.
Meanwhile, there is another mobility management scheme which allows a mobile node to move in a local mobility domain without performing mobility-related signaling. In this mobility management scheme, a proxy entity located in the local mobility domain performs mobility management for the mobile node. Such a mobility management scheme is called network-based mobility management, and is described in later-mentioned Non-Patent Document 2, for example.
The mobile node moving in the local mobility domain connects to the proxy entity by presenting mobile node identification information (MN-ID) during the access authentication processing. This proxy entity is a MAG (mobile access gateway) described in Non-Patent Document 2, for example. The MN-ID is associated with a policy profile of the mobile node which can be acquired from a local server. A policy profile includes a characteristic of the network-based mobility service to be provided, and other related parameters (such as a network prefix assigned to the mobile node (MN. Prefix, for example), a permitted address configuration mode, a mobility policy, and other parameters essential for providing the network-based mobility service).
After the access authentication is successful, the mobile access gateway acquires a policy profile of the mobile node from the local server. This means that the mobile access gateway can hold all information necessary for performing mobility signaling related to the mobile node. Accordingly, the mobile access gateway periodically transmits a router notification including a notification of the network prefix (MN. Prefix) of the mobile node. With reference to the MN.Prefix, the mobile node configures an IP address (such as a home address) to perform communication, for an interface connected to the local mobility domain. The connected interface can refer to the MN.Prefix at any time and any place where the mobile node moves in the local mobility domain. This is made possible since each of the mobile access gateways to which the mobile node connects constantly acquires the profile of the mobile node by making a query to the local server. As a result, the mobile node can always use the firstly-configured IP address for communication, regardless of the position at which the mobile node is connected in the local mobility domain.
To achieve this network-based mobility management, an entity called a local mobility anchor (LMA) serves as a logical anchor point for each mobile node in the local mobility domain. Further, the local mobility anchor manages the reachability state of each mobile node. Accordingly, it can be said that the local mobility anchor is similar to the home agent described in Non-Patent Document 1. To function as the anchoring point for each mobile node, the local mobility anchor needs to update a current position of each mobile node. Hence, every time the mobile node connects to the mobile access gateway, the mobile access gateway transmits a proxy binding update (PBU) message to the local mobility anchor. According to this PBU message, a MN.Prefix and a care-of address of the mobile access gateway are associated with each other. This binding allows the local mobility anchor to transmit a packet to the mobile node through an appropriate mobile access gateway.
FIG. 1 shows an example of a system used in network-based mobility management as described above. In FIG. 1, a local mobility domain 10 includes a local mobility anchor (LMA) 101 and multiple mobile access gateways (MAG) 102, 103 and 104. A mobile node (MN) 11 presents its identification information (MN-ID) in the course of access authentication processing, and connects its interface (IF) 110 to the mobile access gateway (MAG) 102.
After the access authentication is successful, the MAG 102 acquires a policy profile of the MN 11 from the local server based on the MN-ID of the MN 11. This means that the MAG 102 can hold all information necessary for performing mobility signaling for the MN 11. Accordingly, the MAG 102 periodically transmits a router notification including a notification of a network prefix (MN. Prefix) of the mobile node. With reference to this MN.Prefix, the MN 11 configures an IP address of the IF 110 to be used in communication. The IF 110 can always refer to the same network Prefix assigned thereto, regardless of wherever the MN 11 moves in the local mobility domain 10. This is made possible since each of the mobile access gateways to which the MN 11 connects constantly retrieves a profile of the MN 11 from the local server. For example, when the MN 11 moves to the MAG 103 and connects to the MAG 103 via the IF 110, the MAG 103 acquires a network prefix, which is assigned to the MN 11, from the local server based on the MN-ID presented during the authentication processing. As a result, the MN 11 can always use the same IP address for communication, regardless of a place where the MN 11 exists in the local mobility domain 10.
As described above, the LMA 101 not only serves as a logical anchor point for each mobile node, but also manages the reachability state of each mobile node. Since the LMA 101 is the anchoring point for each mobile node, the LMA 101 needs to update a current position of each mobile node. Hence, every time the mobile node connects to the mobile access gateway, the mobile access gateway transmits a proxy binding update (PBU) message to the LMA 101. This PBU message enables the LMA 101 to generate a routing entry for the mobile node by use of identification information unique to the mobile node (MN-ID). In this routing entry, the LMA 101 associates a network prefix assigned to the mobile node with a care-of address of the mobile access gateway. This binding allows the LMA 101 to transmit a packet to the mobile node through an appropriate mobile access gateway. The LMA is also a type of router, and generates a binding entry (sometimes simply called binding) by performing a binding registration. When routing a packet, the LMA refers to the routing entry and then transmits a packet. At this time, the LMA may refer to a binding entry as one of routing entries. Note that routing entries are generated by other routing protocols. Thus, a routing entry can be explicitly generated form a binding entry in a similar manner. In this specification, an entry based on a binding registration is described as a binding entry, and an entry referred to upon routing is described as a routing entry. However, as described above, distinction between the two in an actual embodiment depends on implementation appropriately designed by those skilled in the art, and thus the description of this specification may be interpreted with a binding entry and a routing entry interchanged with each other, or may be understood on the assumption that a routing entry is generated from a binding entry.
In FIG. 1, the MN 11 connects with the MAG 102 by use of the IF 110 and performs necessary authentication processing. After being successfully authenticated, the MAG 102 transmits a PBU to the LMA 101. In accordance with the contents of this PBU, the LMA 101 associates, in a binding cache, a home network prefix or a home address of the mobile node with a care-of address of the MAG 102. When the LMA 110 receives a packet directed to the home address of the MN 11, the LMA 110 checks the binding cache to find a routing path for the packet. Here, the LMA 110 specifies that the packet is directed to the MN 11 and tunnels the packet to the MAG 102 in accordance with the entry in the binding cache. The MAG 102 then transfers the packet to the MN 11.
In recent years, in a network-based mobility management scheme, support for simultaneous access from a multi-interface mobile node has been discussed. Here, since multiple network interfaces are installed to portable electronic devices today, introduction of a function for registering multiple care-of addresses in relation to a certain home address has mainly been discussed. Hereinbelow, this technique is referred to as a multihoming function carried out by a mobile node and/or a router. In the course of this discussion, Non-Patent Document 2 was revised and factors that should be taken into account for the local mobility anchor to support multihoming were pointed out. This revised edition is issued as later-mentioned Non-Patent Document 3.
In addition, in later-mentioned Non-Patent Document 4, a method for registering multiple care-of addresses is described. In this method, each of multiple bindings associated to a home address is identified by use of an identification number called a binding unique identification (BID). A BID is assigned to an interface or a care-of address associated to a home address of a mobile node and/or a router. Accordingly, while the home address is associated to the mobile node and/or the router itself, the BID identifies each binding of a simultaneous access registered by the mobile node. The mobile node uses a binding update (BU) message to notify a home agent of the BID, and the home agent records the BID to its binding cache. Moreover, the mobile node and/or the router may set its preference to the home agent to allow selective routing among traffic flows passing through multiple care-of addresses.
Furthermore, in later-mentioned Non-Patent Document 5, an analysis is made on problems that occur in a local mobility domain when a mobile node performs multihoming by use of the technique disclosed in Non-Patent Document 4. Here, focused is a problem in a case where the local mobility domain is unable to support multihoming because a local mobility anchor lacks some function, and integration of Non-Patent Document 3 and Non-Patent Document 4 is considered.
Here, assume a case where a cellular operator introduces both of techniques disclosed in Non-Patent Document 3 and in Non-Patent Document 4 to the system. It is not hard to imagine that the fourth generation (4G) mobile communication technique developed from the third generation partnership project (3GPP) aims to turn the cellular network into an all-IP system. Similarly, the all-IP system is also studied in the third generation partnership project 2 (3GPP2) of the international mobile telecommunications-2000 (IMT-2000) project. In these projects, most cellular operators consider employment of the technique described in Non-Patent Document 3 as a candidate for satisfying a condition that an object of improving promptness and ease of mobile communication is achieved. In addition, since Non-Patent Document 3 refers to support of multihoming in a local mobility domain, it is highly probable that the cellular network will support multihoming in the future. Further, the technique disclosed in Non-Patent Document 3 is advantageous in that means for carrying out load balancing of data can be implemented in such a system, and a cellular operator can support multihoming.
For example, in FIG. 1, assume that both of the interfaces IF 110 and IF 111 of the MN 11 are simultaneously connected to the local mobility domain 10. Here, the IF 110 is connected to the MAG 102, and the IF 111 is connected to the MAG 103. Both of these connections are registered to the LMA 101. Upon receipt of a packet directed to the MN 11, the LMA 101 can refer to the network condition of the local mobility domain 10 to select which of the MAG 102 or the MAG 103 to cause the packet to pass through in transferring the packet to the MN 11. If the MAG 102 is too overloaded to perform packet processing, the LMA 101 can transfer the packet directed to the MN 11 via the MAG 103 instead of transmitting the packet to the MAG 102. Thus, an advantageous point of supporting multihoming in the local mobility domain is that load balancing can be carried out by the local mobility anchor.
In a case where a cellular operator performs settings to support multihoming in a system, some points may need to be considered. One of the points that need to be considered is to keep the local mobility anchor from being overloaded when supporting multihoming. The local mobility anchor serves as a main device for transmission of packets in a local mobility domain, and it is preferable that the local mobility anchor has a relatively simple configuration in a case of simultaneously handling multiple routing paths to a mobile node. Meanwhile, another point that needs to be considered is that a mobile access gateway need not use a complicated function for supporting multihoming. It is preferable that the mobile access gateway is allowed to support a multi-homed mobile node in accordance with the technique described in Non-Patent Document 4, for example.
In a current task of the IETF (Internet engineering task force), multihoming related to network-based mobility management is considered to be an issue that needs to be dealt with in the coming years. This task will be checked when construction of a basic protocol for network-based mobility management is completed. Accordingly, it is highly probable that a cellular operator will firstly provide a basic network-based mobility management scheme and then integrate support of multihoming into the system. As the cellular operator will test this system at the time of integration of the function, at first, it is likely that both of a mobile access gateway that supports a multi-homed mobile node and a mobile access gateway that does not support a multi-homed mobile node will exist in a system. Moreover, in a case where payment of a license fee is required for each mobile access gateway in using the multihoming function, the operator can minimize the maintenance cost by configuring the multihoming function only to some of the mobile access gateways.
Furthermore, in some cases, not all of cellular operators may desire support of multihoming in the system. If it is determined, in accordance with a consumer market of a specific area, that most of the consumers do not use multihoming, the cellular operator may not provide support for multihoming. In such an environment, particularly when there is a roaming agreement among the operators, it is possible that a multi-homed mobile node may simultaneously connect to a mobile access gateway that supports multihoming and a mobile access gateway that does not support multihoming.